Add multi-worker work support to BeaconProcessor#7720
Add multi-worker work support to BeaconProcessor#7720jimmygchen wants to merge 1 commit intosigp:unstablefrom
Conversation
|
Closing this - will write a new impl. I think there's a fundamental problem with both this solution here and the existing beacon processor - Both async and blocking tasks are handled the same way e.g., some async tasks that wait on network I/O may hold a worker slot unnecessarily. |
|
The async task issue is interesting, maybe we should allow async tasks to go unbounded, and let Tokio's thread pool sort them out? Alternatively we would decrement the number of active workers every time we yield, but I don't think this sounds easy to do |
|
Yeah i think we could potentially try that. Should also keep in mind @paulhauner's comment below - there are some expensive async tasks (e..g. reconstruction - although we might be able to split this one into two tasks - blocking reconstruction + async block import)
|
|
Yeah perhaps we could make the blocking tasks started by async tasks go through the beacon processor so that they are tracked and bounded |
|
Yes, so to summarise:
|
Issue Addressed
BeaconProcessordue to unscopedrayonusage #7719Proposed Changes
(Don't look, the code it splits out is not great 😅 )
Implements generic multi-worker configuration allowing tasks to allocate multiple workers with scoped rayon thread pools:
min(4, max_workers)by defaultspawn_multi_worker()with scoped rayon thread poolsNOTE: This hasn't been reviewed / tested. Please do NOT merge.